home *** CD-ROM | disk | FTP | other *** search
- Date: Mon, 30 May 1994 02:49:02 -0400 (EDT)
- From: Timothy Miller <millert@undergrad.csee.usf.edu>
- Subject: Re: Colour.
- To: gem-list@world.std.com
- In-Reply-To: <9405300406.AA21718@uqcspe.cs.uq.oz.au>
- Message-Id: <Pine.3.87.9405300202.A15807-0100000@undergrad>
- Mime-Version: 1.0
- Precedence: bulk
-
-
- [Below, I state only opinions...]
-
-
- On Mon, 30 May 1994, Warwick Allison wrote:
-
- >
- > As I see it, the major issues with colour palette handling by GEM programs are:
- >
- > - The standard 16 colours
- > - They're different under MultiTOS (right?)
- > - When should a program desire to change them?
- When it's window is topped.
- > - When should a user desire to change them?
- Expound on this questions please.
- >
- > - Sharing colours
- > - No point each program allocating its own Purple
- > - When colours must be changed, it would be nice for
- > the actual palette change to be minimized (eg. purple
- > changes to dark purple, not green)
- Are you sure programmers are going to want to put forth that effort?
- It's much easier to just stick together your palette. How about someone
- write a library routine that, given a new palette, sorts them with respect
- to the palette in place?
-
- > - True Colour emulations
- > - Some programs use a 5x5x5 or 6x6x6 colourspace, and
- > these should all be the same space.
- >
- > - When to change palettes
- > - When window is topped?
- Only this one.
- > - When window is touched in any way?
- In most cases, this would top the window. Under MultiTOS or others,
- where you can use the gadgets without topping the window, the palette
- should NOT be changed to the one for that window... how would you know
- when to change it back?
- > - When mouse enters window?
- Too difficult... requires that something watch the mouse pointer.
- >
- >
- > Some time ago, I posted a draft proposal for this, but it was probably
- > a too-complex proposal, and so I would like to hear of any conventions
- > currently in use.
- >
- > As a first point of discussion, what are the pros and cons of a simple
- > system like this:
- >
- > Each application sets the palette whenever one of its windows
- > is topped. They use colours above 15 if available.
- >
- > --
- > Warwick
- >
- Your proposal is sound, however, since not all apps will follow this, and
- the WM_TOPPED signal is broadcast globally, perhaps apps should set the
- palette BACK to what it was before when it's window is untopped? The
- only problem with that is if the newly topped app sets a palette before
- the old one resets the palette... this would cause a conflict.
-
- For colors, an app should scan all available colors and see what it can
- match to. When changing the palette, it should favor using those above 15.
-
- Since GEM is too free about this, this one is going to be tough for us to
- work out, especially since no-one before will have followed these rules,
- yet we'll have to tollerate their apps.
-
-
-